Kritični ranljivosti PHP (PHP2Shell): objavljeni nujni varnostni popravki

21. oktober 2026 – posodobljeno po 16. uri: Razvijalci PHP so izdali nujne varnostne popravke za CVE-2026-109618 in CVE-2026-109619 (PHP2Shell). Ranljivosti lahko omogočita izvajanje kode brez prijave, zato je priporočena čimprejšnja nadgradnja. V nadaljevanju so navedene popravljene različice, stanje ponudnikov paketov in začasni ukrepi.

POSODOBLJENO 21. 10. 2026 po 16. uri: popravki PHP so objavljeni

Uradna varnostna posodobitev je zdaj na voljo. Razvijalci PHP so potrdili, da lahko CVE-2026-109618 in CVE-2026-109619 pod določenimi pogoji omogočita oddaljeno izvajanje kode brez prijave. Izpostavljene so tudi namestitve s PHP-FPM, mod_php, php-cgi, LiteSpeed in FrankenPHP. Posebej veliko tveganje je potrjeno pri mod_php. Spodnji del članka o pričakovani izdaji popravkov opisuje stanje dopoldne, pred njihovo objavo.

Popravljene različice PHP

Varnostna ekipa PHP je zaradi resnosti izjemoma objavila tudi minimalne izvorne popravke za PHP 7.4, 8.0 in 8.1. Ti niso enako kot že nameščeni binarni popravki za vaš strežnik. Za najstarejše veje je zato treba posebej preveriti pakete in dejansko vključitev popravka. PHP 8.2 bo konec leta 2026 dosegel konec uradne podpore.

cPanel/EasyApache 4 in CloudLinux

Uradna izdaja na php.net še ne pomeni samodejno, da so popravljeni paketi že na voljo v vseh repozitorijih. Pri cPanel/WHM mora administrator ločeno preveriti ustrezne različice paketov ea-php v EasyApache 4 in njihovo razpoložljivost v uporabljenem repozitoriju. Na strežnikih CloudLinux je treba preveriti tudi alt-php oziroma posebne varnostno vzdrževane veje; ob zadnjem preverjanju CloudLinux še ni potrdil izdaje vseh novih paketov alt-php.

CloudLinux je potrdil, da je Imunify360 ModSecurity ruleset 8.83 v stabilnem kanalu in blokira javno poznani vzorec napada prek PHP session upload progress. Če sta Imunify360 in njegov WAF/ModSecurity aktivna, se pravila samodejno prenesejo. Vendar gre samo za začasno zaščito pred določenim načinom napada, ne za odpravo ranljivosti.

Začasni ukrepi, kadar takojšnja nadgradnja ni mogoča

PHP je podal naslednja priporočila za zmanjšanje izpostavljenosti, ne pa za popolno zaščito:

• Za CVE-2026-109619 nastaviti session.upload_progress.enabled=0 v dejanski strežniški konfiguraciji PHP in ponovno zagnati vse ustrezne PHP procese. Sprememba na ravni aplikacije z ini_set() ni ustrezna zaščita.
• Za PHP 8.5 je priporočeno tudi fatal_error_backtraces=0, kar prepreči enega od potrjenih načinov izkoriščanja.
• Za CVE-2026-109618 PHP med začasnimi ukrepi navaja memory_limit=-1, vendar to spremeni omejitve porabe pomnilnika. Na deljenih ali produkcijskih strežnikih se takšne nastavitve ne sme uvajati nepremišljeno; potrebni so preizkus, nadzor in omejitve na ravni procesov oziroma vsebnikov.
• Smiselna je tudi omejitev velikosti prejetih POST zahtevkov in števila vhodnih polj ter odprava dosegljivih kritičnih napak in časovnih omejitev.

Ključno priporočilo: namestite popravljeno različico PHP oziroma preverjen popravek dobavitelja paketov čim prej. Po nadgradnji preverite vse PHP različice, ki jih uporabljajo spletne strani, ponovno zaženite ustrezne storitve in preverite delovanje aplikacij.

Uradni viri: PHP Security Advisory, 21. 10. 2026, CloudLinux – status popravkov, cPanel – EasyApache 4 Change Log.

Prvotno opozorilo (objavljeno 21. 10. 2026 dopoldne)

Kaj se je zgodilo?

Varnostna ekipa PHP je 20. oktobra 2026 izdala predhodno opozorilo o dveh kritičnih varnostnih težavah v samem PHP. Uradna objava popravkov je predvidena za sredo, 21. oktobra, ob 14.00 UTC oziroma ob 16.00 v Sloveniji. Ekipa je opozorila, da lahko popravke izda tudi predčasno, če bi prišlo do javnega razkritja podrobnosti ali zaznanih napadov.

Varnostni raziskovalci poročajo o možnosti oddaljenega izvajanja kode (RCE), kar pomeni, da bi napadalec pod določenimi pogoji lahko izvajal ukaze na ranljivem strežniku. Natančni tehnični pogoji, seznam prizadetih različic in popravljene izdaje v času priprave tega članka še niso bili uradno objavljeni. Zato ni pravilno trditi, da je ranljiva prav vsaka namestitev PHP ali da je napad že potrjeno razširjen.

Zakaj je opozorilo pomembno za WordPress in spletne trgovine?

PHP poganja veliko spletnih strani, tudi sisteme WordPress, WooCommerce ter številne druge spletne aplikacije. Če je težava v samem PHP, samo posodobitev WordPressa, vtičnikov ali teme morda ne bo dovolj. Pomembna je tudi različica PHP, ki dejansko obdeluje zahteve spletne strani, in konfiguracija strežnika.

Ranljivost ne pomeni samodejno, da je bila vaša spletna stran napadena. Pomeni pa, da mora skrbnik preveriti, katere različice PHP uporablja in kako bo namestil ustrezne popravke, ko bodo na voljo.

Kaj lahko naredite že pred 16. uro?

• Preverite, katero različico PHP uporablja posamezna spletna stran. Na istem strežniku jih lahko deluje več.
• Preverite, kdo skrbi za varnostne posodobitve: ponudnik gostovanja, sistemski administrator ali vi sami.
• Pripravite aktualno varnostno kopijo spletne strani in podatkovne baze ter preverite možnost obnove.
• Pripravite načrt za posodobitev PHP in preverjanje delovanja spletne strani po njej.
• Če uporabljate zastarele različice PHP, načrtujte prehod na podprto vejo oziroma pri ponudniku preverite možnost posebnih varnostnih popravkov.
• Pri posebej izpostavljenih sistemih ocenite začasno omejitev dostopa, dokler niso nameščeni popravki.

Ali pomaga izklop session.upload_progress?

Med predlogi za začasno omejitev tveganja se pojavlja izklop funkcije, ki spremlja napredek nalaganja datotek. V ustrezni konfiguraciji PHP se nastavi:

session.upload_progress.enabled = 0

PHP-jeva uradna dokumentacija že sicer opozarja na varnostna tveganja te funkcije v določenih okoliščinah. Nekateri raziskovalci menijo, da bi njena izključitev lahko zmanjšala izpostavljenost vsaj eni od novih ranljivosti. Vendar to ni uradno potrjena zaščita pred obema ranljivostma in ni nadomestilo za varnostno posodobitev. Pred spremembo je treba preveriti, ali spletna aplikacija funkcijo uporablja, v kateri datoteki oziroma upravljavskem vmesniku je nastavitev učinkovita in ali je sprememba dejansko začela veljati.

Kaj pa starejše različice PHP?

Posebno pozornost zahtevajo aplikacije, ki še vedno uporabljajo PHP 7.4, 8.0, 8.1 ali druge nepodprte veje. Zanje običajni uradni varnostni popravki niso več zagotovljeni. Nekateri komercialni ponudniki, na primer za okolja CloudLinux in storitve podaljšane podpore, lahko zagotavljajo ločene popravke. Na njihovo razpoložljivost se ne smemo zanašati brez izrecne potrditve ponudnika.

Pomembno: do objave tehničnih podrobnosti ni mogoče zanesljivo potrditi, katere starejše različice in konfiguracije sta ranljivosti dejansko prizadeli. Nadgradnja zastarelega PHP pa je v vsakem primeru priporočljiva zaradi drugih že znanih varnostnih tveganj.

Kako posodobiti PHP pri cPanel/WHM in AlmaLinux?

Na strežnikih z AlmaLinux in cPanel/WHM se PHP pogosto upravlja z EasyApache 4, v nekaterih okoljih pa tudi z dodatnimi sistemi, kot je CloudLinux PHP Selector. Ukazi za Ubuntu, na primer apt update, niso univerzalno uporabni za takšno okolje. Samo izvajanje dnf update brez preverjanja nameščenih paketov prav tako ni zagotovilo, da je bila posodobljena prava PHP različica.

Administrator mora ugotoviti, katere izdaje PHP so nameščene, katere uporabljajo posamezne domene, od katerega ponudnika prihajajo paketi in kdaj bodo na voljo popravljene izdaje. Po posodobitvi mora preveriti različice, delovanje PHP-FPM oziroma drugih PHP načinov izvajanja ter pravilno delovanje spletnih strani.

Kaj storiti po objavi popravkov?

Ko bodo popravki uradno izdani, je treba najprej preveriti seznam prizadetih in popravljenih različic. Nato je treba posodobiti vse uporabljene ranljive PHP izdaje, preveriti, da spletne aplikacije dejansko uporabljajo popravljene različice, in opraviti funkcionalni preizkus strani, obrazcev, prijavnih postopkov ter spletnih trgovin.

Če uporabljate deljeno spletno gostovanje, za posodobitev strežniškega PHP praviloma skrbi ponudnik gostovanja. Če upravljate lasten VPS ali namenski strežnik, morate ukrepanje uskladiti s svojim administratorjem. Pri obeh možnostih je pomembno, da uporabljate podprto in vzdrževano okolje.

Uradni viri in dodatne informacije

• Uradno opozorilo PHP Security Team
• Varnostno opozorilo CERT-EU
• Stanje pripravljenosti popravkov CloudLinux
• Dokumentacija PHP: nastavitve sej

Opomba uredništva: prispevek odraža informacije, ki so bile javno dostopne 21. oktobra 2026 dopoldne, pred napovedano objavo popravkov ob 16.00. Podatki o prizadetih različicah in ustreznih popravkih se lahko po uradni objavi spremenijo.